Won't int(ret) potentially truncate on 32 bit platforms?

ret is a uint32, so I don't think it will overflow. What will happen if len(src) don't fit in 32 bits is that this function will panic. I guess this behavior is right, at least I won't feel comfortable batching encrypts/decrypts in 32 bit chunks unless a crypto expert says we can do it.

Another thing to look at is signed values: https://go.dev/play/p/ZQXsT1GlEPQ

	var v uint64 = math.MaxUint64 // 64 to match platform-sized int in playground
	fmt.Printf("%x %x\n%x\n", v, int(v), math.MaxInt)

ffffffffffffffff -1
7fffffffffffffff

But I think it's ok here, because int is 32-bit, and len returns an int, then the size of the slice is limited to the positive 31 bits and this will never occur. If bcrypt.Decrypt is misbehaving and returns a large value that casts to a negative int, that will always panic because len(src) always returns a positivenon-negative int. (And we want a panic in this case.)